Large distributed systems can be simulated using multiple simulators linked through a network which cooperate to simulate the desired system or architecture. It has been recognized that the ability to simulate such architectures can produce more optimal results by enabling decision-makers to carry out, ahead of time, what-if type analysis. Such capabilities enable decision-makers to detect problems in the real-time operation of proposed systems or processes long-prior to implementation of an associated process or activity.
In a context of simulation of training exercises, various models of entities can be used which inter-operate with one another to test, verify and validate the static architecture of the system or process. One such system, known as Federated Executable Architecture Technology (FEAT) has been described in “Federated Executable Architecture Technology as an Enabling Technology for Simulation of Large Systems”, Harrison et al., Proceedings of the SPIE, vol. 62270E, June 2006.
The executable architecture is ‘federated’ meaning that a simulation federation is set up so that multiple simulators can share information such as entity state, as long as the various simulators maintain a certain protocol in the communication in the federation, they can all work together. Executable architectures define one or more processes and carry out simulations thereof, which among the results enables a determination to be made as to elapsed time to carry out a respective process.
In the FEAT system, a mechanism is present to federate just about any type of simulator, including constructive simulators into the federation using a federated Petri-Net technology. A Petri-Net works by passing indicia or data around the system, for example, an object that represents a certain type of message.
In early, basic Petri-Nets, there are nodes that can communicate with each other by passing balls around the nodes. A node can't fire until it receives a ball. Subsequent revisions include colored Petri-Nets, where the nodes require a certain color ball before they fire and send their ball into the system to the next connected node. These Petri-Net systems were intended to help simulate the operation of parallel processes with multiple pathways.
In the Petri-Net version incorporated in FEAT the colored balls have been replaced with particular messages. Each message can carry extra payloads, such as location information. Time can also be incorporated in the Petri-Net, by requiring each node to wait for a predetermined time before releasing its message into the environment. All messages are transmitted via a High Level Architecture (HLA) network of a type usually used for virtual and constructive simulation object-oriented traffic. As long as a simulator provides the correct interface to the HLA network (This interface is described by a Federated Object Model (FOM)), then it can cooperate in the simulation.
While such systems and processes can be implemented to proceed substantially automatically without human intervention, it has also be recognized that introduction of one or more operators or actors into the process can not only be used to enhance the training experience of the respective individual or individuals but can also result in the incorporation of those individuals' real-world experiences into the simulation process. Thus, there is a continuing need to be able to incorporate operator or individual inputs into such systems in real-time.
Additionally, it would also be desirable to enable such persons or individuals to evaluate alternative courses of action during the process. It would also be desirable to be able to create or update an architecture by recording the simulation of events over a period of time during the ongoing process. Preferably, the actions of the participating individual become a part of the larger architecture, thus enhancing the realism of the simulation and also extending the current architecture.